Today, a multitude of services can be executed in a communication services network according to specifications provided in electronic service documents. The Open Mobile Alliance OMA has defined standards for creating and handling the service documents which thus contain service related information that may be useful or required for executing one or more services and applications in a mobile or cellular network. According to common practice, these service documents are in the format of XML (Extensible Markup language) basically defining a set of rules for encoding documents in machine-readable form. The service documents are handled and maintained by so-called XMLDocument Management Servers, commonly referred to as “XDMS”. The service documents are also commonly referred to as “XDM documents”.
Service documents may be defined for specific users in a communication services network with instructions and parameters to be used for executing one or more services specifically for the users. For example, a service document may contain a list of contacts, or “friends”, of the user, e.g. to be used when executing a presence service. This list may be required when executing a number of different services, each service being controlled, defined or dictated by a service document that may be user-specific or general. In order to avoid duplication of data, the list may be provided in full in just one service document while the other documents contain a brief reference to the list for retrieval from the former document. In this way, the same list or the like with information can be reused in multiple service documents without duplication of all data therein.
In other examples, a set of instructions, rules or policies may be provided in full in one document and a reference thereto may be included in other service documents requiring the same information. In this description, the term “service related information” will be used to represent any information needed for executing a communication service, such as the above mentioned examples of a contact or member list, and a set of instructions, rules and/or policies.
When a user terminal, an application server or the like shall execute a specific service for a user, the terminal or server will fetch the corresponding service document from a document server. If the fetched document contains a reference to a list or other service related information available in another service document, that other document must be fetched as well, possibly from another document server, in order to obtain all necessary information for executing the service. Any terminal or server that retrieves a service document from a document server, e.g. for executing a communication service or application, will be referred to as a “requesting party” in the following.
FIG. 1 is a signalling diagram illustrating a scenario when a requesting party 100 retrieves service related information required for executing a specific service for a user, according to a conventional solution. In a first shown action 1:1, the requesting party 100 sends a request for a first document “Doc 1” to a first document server 102 from which the document can be retrieved. The document server 102 then retrieves the first document in a next action 1:2, e.g. locally from a document storage or the like, and returns that document in a response to the requesting party 100, in a following action 1:3.
Having discovered that the received document Doc 1 contains a reference to needed service related information in a second service document, but not the information itself, the requesting party 100 is forced to send a request for the second document“Doc 2”, using the information reference from Doc 1, to a second document server 104 in a further action 1:4. The document server 104 then retrieves the second document in a next action 1:5, and returns that document in a response to the requesting party 100, in a final shown action 1:6.
The requesting party 100 is thus obliged to fetch a service document twice, i.e. the first document containing service specifications and the information reference, and then the second document containing the referenced service related information, in order to obtain all information needed to execute the service. In some cases, information in more than one service document may be referenced in a first retrieved service document and/or further information references may occur in a “chain” of referenced documents, and so forth. This behavior of retrieving information from multiple documents can be rather time-consuming and also requires a certain amount of processing and messaging by the requesting party 100 as well as bandwidth for the communications involved.
Furthermore, the requesting party 100 must be capable of accessing both document servers 102 and 104 and also of understanding the structure of both its own service document Doc 1 and the referenced document Doc 2, in order to find and retrieve the needed information. Consequently, the requesting party 100 must know the host address of both document servers 102 and 104, and generally, information on document servers holding such service related information must somehow be distributed to requesting parties and be kept up-to-date as well. The above requirements generally result in a relatively complex implementation for the handling of service documents as well as undue delays, particularly when chained references are used in multiple documents.